The python 3.10 build is producing a lot of warnings (this currently also happens on main)

test/cirq_utils/test_parallelize.py: 9170 warnings
test/qasm2/test_native.py: 1873 warnings
  /Users/rafaelhaenel/Documents/quera/kirin-workspace/.venv/lib/python3.10/site-packages/cirq/circuits/circuit_operation.py:173: FutureWarning: In cirq 1.6 the default value of `use_repetition_ids` will change to
  `use_repetition_ids=False`. To make this warning go away, please pass
  explicit `use_repetition_ids`, e.g., to preserve current behavior, use
  
    CircuitOperations(..., use_repetition_ids=True)
    warnings.warn(msg, FutureWarning)

These warnings are coming internally from cirq 1.5.0. The solution is to simply upgrade to cirq 1.6 which requires Python 3.11 (which is why only the 3.10 build has these issues).

I've gone ahead and filtered these warnings.

This is somewhat hacky. correlated_qubit_loss is an n-qubit operator. As far as I know all other operators act on either one or two qubits.

Stim does not support n-qubit operators, which is why the nonce workaround is introduced.

I'm wondering if broadcast should be disallowed for this type of operator? Instead only use apply? I am a bit confused how that works after the refactor.

This mismatch in semantics is a concern. There are a couple stim gates that act on more qubits: MPP, SPP, and SPP_DAG

# Perform a SQRT_YY gate between qubit 1 and 2, and a SQRT_ZZ_DAG between qubit 3 and 4.
SPP Y1*Y2 !Z1*Z2

What are the requirements here? Do we really need to support correlated loss for more than two qubits at a time? If so, it's probably best to make this statement apply to an IList[IList[Qubit]] or similar. All statements in the gate dialect should "broadcast", meaning that it applies to each entry in the list of arguments.

@cduck are you saying we need to support statements for these gates? Or are you just pointing out that these would be points where this noise process can be injected and so we have more than two qubits here?

From the example @cduck sketched out for me I think it should be an arbitrary number of atoms.

From Casey himself:

What I mean is
I_ERROR[CORRELATED_LOSS:<nonce>](p) 1 2 3
Is there is a chance p that a single event that looses all atoms 1, 2, and 3 occurs.

Briefly chatted with @david-pl , IList[IList[Qubit]] makes sense here.

In the apply case you just accept a single list of qubits (if one atom in the list goes, all the other ones get lost too)

In the broadcast case you accept list of lists, if any atom in one of those sublists goes, then the other atoms should go too

yes in the case of SPP is why we have discussion whether we need PauliString Type or something to express a pauli-string. iirc the conclusion is to just use string "XYXXYZ" to represent SPP in stim dialect, and no support for it in squin?

We don't need to have an equivalent of the SPP command in kirin-stim at all. This is a really niche gate that we don't need. I was just using that as an example of a more complex stim instruction than I_ERROR.

@cduck are you saying we need to support statements for these gates? Or are you just pointing out that these would be points where this noise process can be injected and so we have more than two qubits here?

@david-pl, I'm throwing out ideas for stim gates that can be repurposed to represent correlated atom loss. SPP isn't a great option but shows how stim can group qubits.

@cduck ok so thats align with what we discuss earlier with @ChenZhao44 that we don't really have need of SPP. For the tag. If thats the behavior of stim, then, is the quest here that you want to also preserve the command order in stim circuit python instance (i.e. don't want stim to auto merge? so we need separate tags?)

broadcast.correlated_qubit_noise has now been updated to accept qubits: list[list[Qubit]]